Faculty  Working  Papers 


ONE  FIRM'S  EXPERIENCE  WITH  AN 
ADVANCED  DATA  MANAGEMENT  SYSTEM 

Hirohide  Hinomoto 


#200 


College  of  Commerce  and  Business  Administration 

University  of  Illinois  at  Urbana-Champaign 


FACULTY  WORKING  PAPERS 
College  of  Commerce  and  Business  Administration 
University  of  Illinois  at  Urbana -Champaign 
August  26,  1974 


ONE  FIRM'S  EXPERIENCE  WITH  AN 
ADVANCED  DATA  MANAGEMENT  SYSTEM 

Hirohide  Hinomoto 


#200 


>r-o:> 


::':>■■'::'  1  '.II 


r 


ONE  FIRM'S  EXPERIENCE  WITH  AN 
ADVANCED  DATA  MANAGEMENT  SYSTEM 


Hirohide  Hinomoto 

Department  of  Business  Administration 
University  of  Illinois 
Urbana -Champaign,  Illinois  61801 


Digitized  by  the  Internet  Archive 

in  2012  with  funding  from 

University  of  Illinois  Urbana-Champaign 


http://www.archive.org/details/onefirmsexperien200hino 


ABSTRACT 

The  organization  under  investi£  ition  initially  tried  to  develop  an 
advanced  database  management  system  completely  in-house,  but  the  develop- 
ment effort  was  subsequently  abandoned  in  favor  of  the  use  of  IMS.  The 
organization  used  all  versions  of  IMS  available  during  the  period  of 
1970-1973,  gradually  accumulating  experience  with  this  difficult  system. 
One  serious  problem  it  faced  in  a  few  occasions  was  excessively  long 
response  time  at  the  terminal,  created  by  contention  between  messages 
trying  to  update  the  same  segment  type  within  a  database.  This  is  but 
one  of  many  problems  created  by  both  the  design  deficiencies  of  IMS 
and  the  unfamiliarity  of  programmers,  who  had  been  trained  in  batch 
environment,  with  on-line  processing  of  terminal  messages.  Further,  it 
became  evident  to  the  organization  that  establishing  the  function  of 
database  administration  was  essential  for  further  enhancement  in  the 
use  of  IMS. 


Introduction 

This  article  presents  a  detailed  account  on  the  decision  to  use  and 
experience  with  IMS,  perhaps  the  most  flexible  database  management  system 
in  existence,  at  a  large  industrial  firm.   The  effective  use  of  an 
advanced  database  management  system  in  online  processing  environment  is 
no  doubt  one  of  the  most  challenging  problems  in  information  processing 
that  face  most  large  organizations  during  this  decade.   It  is  believed 
that  hundreds  of  organizations  are  already  using  advanced  database  management 
systems,  but  only  a  very  limited  number  of  them  enjoy  mastery  of  their  systems 
The  experience  of  a  predecessor,  whether  success  or  failure,  is  a  valuable 
lesson  for  a  follower.   Further,  detailed  accounts  on  such  an  experience 
are  useful  information  to  information  systems  scientists  in  identifying 

subjects  of  research  that  contribute  to  informative  processing  in  the 
real  world.   Unfortunately,  such  accounts  are  very  difficult  to  find  in 
literature.   This  article  describes  chronological  events  taken  place 
regarding  the  use  of  IMS  at  the  firm  over  a  period  of  five  years  since  the 
pre-installation  preparation  in  19o9,  and  tries  to  show  types  of  problems 
encountered  by  the  firm  in  the  use  of  the  system. 

IMS  is  a  database  management  system  developed  by  IBM  to  facilitate  the 
implementation  of  medium  to  large  common  data  bases  in  a  raultiapplication 
environment.   It  can  accommodate  both  online  message  processing  and  con- 
ventional batch  processing,  either  separately  or  concurrently.   IMS  uses 
the  language  called  Data  Language/I  (DL/I)  to  create  and  maintain  data- 
bases and  to  process  terminal  messages.   The  system  was  first  developed 
as  a  joint  product  of  IBM  and  the  North  American  Rockwell  Company  in  1965. 
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Subsequently,  it  was  released  as  a  program  product  with  IBM's  full  support 
in  September  of  1968,  has  gone  through  a  sequence  of  improvements,  and  is 
expected  to  have  a  radically  improved  version  in  early  1974.   There  are  a 
number  of  database  management  systems  commercially  available  some  of  which 
have  proved  to  be  superior  to  the  existing  version  of  IMS,  IMS2,  in  response 
time  and  throughput  under  certain  environments.   But  none  of  them  has  the 
range  of  flexibility  and  established  interfaces  to  additional  software 
available  to  IMS.   Its  flexibiblity  is  achieved  by  placing  a  heavy  burden 
on  programmers  at  the  user  organization.   It  is  a  difficult  program  to 
understand  for  a  systems  programmer  and  requires  an  application  programmer 
to  follow  complicated  rules  to  define  databases  for  application 
programs.  As  a  result,  even  large  organizations  have  failed  to  master 
the  use  of  the  system.   The  flexibility  of  IMS  is  believed  to  be  the  very 
cause  of  much  of  the  confusion  currently  surrounding  the  system. 

To  understand  the  function  of  IMS,  the  sequence  of  events  with  which 
it  processes  the  message  is  shown  in  Figure  1  and  explained  below: 

(1)  The  operator  enters  a  mes  age  from  the  terminal  keyboard  and 
waits  its  output  to  be  displayed  on  this  terminal. 

(2)  IMS  receives  the  message  and  writes  information  regarding  the 
content  of  the  message  and  the  receiving  time  on  the  log  tape. 

(3)  The  message  is  placed  in  the  input  queue  provided  for  its  type. 

(4)  When  it  advances  to  the  front  of  the  queue  and  a  region  provided 
for  its  type  becomes  available,  the  message  is  removed  from  the 
queue  and  given  a  predetermined  priority  of  processing.   This 

is  called  scheduling. 
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Figure  1.   Sequence  of  Events  in  Processing 
a  Terminal  Message  with  IMS. 
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1.  Enter  a  terminal  transaction. 

2.  Receive  the  transaction  and  log  the 
transaction  content  and  receiving  time. 

3.  Place  the  transaction  in  the  input  queue. 

4.  Remove  the  transaction  from  the  queue 
for  scheduling  and  log  the  time. 

5.  Process  database  segments:  for  an  inquiry  only,  no  log; 
for  an  update,  log  images  before  and  after  the  process. 

6.  Generate  output  for  terminal,  put  in  the  output 
queue  and  log  the  output. 

7.  Send  back  secondary  transactions  generated  by  th* 
original  transaction  to  the  queue    (Event  3V 

8.  Complete  the  process  and  log  the  time. 

9.  Send  the  output  to  the  output  queue  and  log  the  time. 
10.  Remove  th*  output  from  the  output  queue. 

11..  Display  the  output  on  the  terminal. 
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(5)  IMS  obtains  the  database  segments  required  by  the  message,  places 
them  in  a  message  regior   and  processes  them  according  to  the 
message  codes.   If  the  message  is  an  inquiry  only,  nothing  is 
stored  on  the  log  tape  whereas,  if  the  message  is  an  update. 

the  contents  of  the  database  segments  before  and  after  the 
process  are  recorded  on  the  log  tape, 

(6)  The  output  is  generated  and  placed  in  the  output  queue.   At  this 
time,  its  content  is  stored  in  the  log  tape. 

(7)  The  secondary  messages  created  by  the  terminal  message  are  placed 
in  the  input  queue  in  (3)  above.   From  (3)  to  (7)  will  be  repeated 
whenever  a  preceding  message  generates  successor  messages. 

(8)  Upon  completion  of  the  process  of  the  current  message,  IMS  records 
the  time  on  the  log  tape. 

(9)  IMS  places  the  output  of  the  current  message  in  the  output  queue 
and  records  the  time  on  the  log  tape. 

(10)  The  output  placed  in  the  queue  in  (6)  or  (9)  is  removed  from 
the  queue  and  sent  to  the  display  terminal. 

(11)  The  terminal  displays  the  output  received. 

The  actual  processing  of  a  message  is  done  as  events  (A)  -  (8)  in  a 
message  region.   Immediately  before  and  after  this  process,  the  message 
resides  in  the  control  region  under  the  control  of  its  control  program  as 
input  in  events  (2)  -  (3)  ot  as  output  in  event  (8) .   During  the  period 
between  event  (2)  and  event  (9)  ,  the  message  is  subject  to  processing  by 
the  CPU.   However,  a  terminal  message  does  not  necessarily  go  through  the- 
entire  sequence  of  events  in  one  continuous  pass.   It  may  generate  a  chain  of 
background  messages  each  of  which  goes  through  the  cycle  of  events  (3)  -  (7) . 


When  finally  the  last  of  the  background  messages  is  completed,  that  time 
determines  the  response  time  of  the  original  message.   This  response  time 
may  well  be  different  from  the  response  time  in  the  eyes  of  the  terminal 
operator,  because  the  required  output  to  the  terminal  may  be  completed 
while  background  messages  are  still  being  processed.   IBM  provides  a  utility 
program  that  produces  daily  statistical  data  on  the  use  of  IMS.   The  data 
include  the  frequency  distribution  of  terminal  messages  (including  their 
background  messages)  by  type  per  clock  hour  and  six  different  response 
times  --  the  shortest,  longest,  and  four  quartile  response  time  figures  -- 
for  each  message  type  processed  during  the  day.   However,  this  utility  program 
is  not  adequate  for  allocating  the  CPU  time  to  different  message  types  for 
a  costing  purpose. 

The  firm  in  this  study  was  composed  of  several  operating  divisions 
with  decentralized  computer  activities  with  each  division  having  its  own 
computer  center  and  programming  personnel.   Corporate  Director  of  Infor- 
mation Systems,  directly  reportin  to  Vice-President  of  Finance,  controlled 
all  acquisition  and  renting  of  computer  equipment  by  divisions  and  coordi- 
nated major  computer  activities  at  these  divisions.  For  example,  he  had 
power  to  support  or  refuse  the  use  of  IMS  by  a  division.   On  the  other  hand, 
the  divisional  manager  of  information  systems  had  complete  authority  over 
computer  personnel  and  programs  to  be  developed.  The  division  studied  here 
was  the  largest  division  in  the  corporation,  produced  industrial  electronic 
goods  with  a  total  value  exceeding  $600  million  dollars.   At  this  division, 
programming  people  were  grouped  into  the  systems  (programming)  group  and 
the  application  (programming)  group.   The  former  group  was  composed  of  a 
manager  and  ten  systems  programmers.   Problems  related  to  IMS  were  handled  by 
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the  manager  of  systems  programming,  two  systems  programmers,  and  a 
resident  IBM  systems  programmer.  Tost  of  them  have  engaged  in  the 
maintenance  of  IMS  since  its  initial  installation  at  this  division 
in  1970.  The  application  group  was  composed  of  a  manager  and  some  30 
programmer-analysts  who  were  located  a  few  miles  from  the  computer 
center,  the  location  of  the  systems  group.   The  physical  separation  of 
these  groups  created  difficulty  in  communications  and  cooperation  that 
frequently  produced  mutual  suspicions.   Small  problems  that  could  be 
solved  informally  at  an  early  stage  in  a  normal  organizational  enviorn- 
ment  tended  to  be  left  untouched  until  they  became  serious  formal  issues 
between  the  two  groups.   In  general,  systems  programming  personnel 
felt  they  were  running  a  service  bureau  trying  to  please  whatever 
demands  made  by  the  application  group. 

Pre- Installation  Period.  1969-1970 

In  1969,  the  information  systems  group  of  this  division  was  considering 
a  broad  scope  improvement  in  its  information  processing  operation  in 
conjunction  with  the  necessity  of  developing  an  application  program  to 
handle  the  issue  and  control  of  engineering  documents.   One  of  the  serious 
problems  needing  immediate  attention  was  to  maintain  all  existing  batch 
processing  programs  without  redundant  processes  that  existed  excessively 
among  these  programs.   For  example,  one  batch  program  processed  the  same  file 
in  seven  different  ways  at  seven  different  points  in  time  when  in  fact  these 
processes  could  have  been  combined  into  one.   Further,  information  on  most 
items  produced  by  the  division  was  typically  stored  in  more  than  one  file. 
This  was  partly  due  to  multi-point  warehousing  and  distribution  system  of 
the  division.   Standard  items  were  kept  at  four  warehouses,  one  for  each  of 
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the  four  types  of  customers  --  distributors,  original  equipment  manufacturers, 

internal  customers,  and  educational  users.   To  be  worse,  separate  iventory 

files  were  kept  by  the  warehousing  and  shipping  groups  within  each  warehouse, 

thus  creating  discrepancies  in  item  volumes  recorded  in  these  files.   In 

addition,  different  groups  used  different  terms  for  the  same  item  or 

followed  different  procedures  for  the  same  job,  which  constantly  created 

problems  of  communication  and  coordination.   Further,  where  product  lines  were 

composed  of  components  produced  by  groups  under  different  managers,  the 

allocation  of  profit-and-loss  figures  to  these  managers  was  not  clearly 

defined.   To  the  information  systems  group,  these  organizational  deficiencies 

were  the  causes  for  operational  inefficiencies  manifested  by  the  excessive 

amount  of  time  required  for  the  shipment  of  items  available  in  inventory 

or  the  production  and  shipment  of  items  not  available  in  inventory  after 

an  order  was  received.   The  group  judged  that  ever  increasing  demands 

for  the  products  of  the  division  were  making  the  problems  for  the 

worse. 

It  was  this  general  condition  that  led  the  information  systems  group 

to  conceive  an  idea  of  entering  data  at  different  sources  into  common 

databases,  and  retrieving  and  updating  them  simultaneously  by  different 

operators.  This  meant  the  consolidation  of  all  files  into  common  databases, 

the  independence  of  the  databases  from  application  programs,  and  a  change  in 

computer  environment  from  batch  processing  to  online  timesharing  processing. 

The  fermentation  of  these  ideas  took  place  early  in  1970  under  the  guidance 

of  the  group's  manager  with  an  extensive  experience  in  developing  software 

for  a  time-sharing  system  at  another  firm. 
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After  studying  all  commercial  database  management  systems  then  available, 
the  group  concluded  that  none  of  them  could  meet  the  particular  needs  of 
the  division,  and  decided  to  develop  a  system  specifically  designed  for 
these  needs  and  therefore  more  efficient  than  the  commercial  systems.  As 
the  first  objective,  the  proposed  system  was  to  process  the  application 
program  for  issue  and  control  of  engineering  documents  that  was  scheduled 
to  start  its  development  soon.   The  group  further  planned  to  interphase  all 
future  application  programs  developed  in-house  with  the  database  management 
system.   Subsequently  in  the  spring  of  1970,  two  separate  teams  were  formed; 
a  team  of  12  people  was  to  develop  completely  in-house  the  database  management 
system  with  a  code-name  EDOM,  and  the  other  team  of  eight  people  an  applica- 
tion program  for  the  document  issue  and  control  system  using  a  common  data- 
base.  The  latter  program  was  called  ICED  and  its  target  date  of  completion 
was  September  1970.   At  that  time,  database  management  systems  were  still 
considered  problems  in  the  frontier  of  data  processing.  As  a  result,  the 
members  of  the  EDOM  team  were  enth  siastic  about  their  task  to  develop  a 
system  superior  to  any  existing  one.   However,  while  the  project  was  in 
progress,  the  team  kept  open  the  question  of  whether  to  continue  its 
effort  or  to  adopt  a  commercially  available  one. 

Time  passed  quickly,  while  the  EDOM  team  was  still  laying  out  a 
master  plan  for  the  database  management  system.   It  was  already  mid-July 
1970  when  the  information  systems  group  finally  decided  to  abandon  the 
effort  of  developing  EDOM  and  in  its  stead  to  adopt  IBM's  IMS.   The  group 
considered  IMS  to  be  the  only  commercial  system  suitable  to  the  division's 


8 
complex  operation.   The  decision  to  discontinue  the  project  was  based  on 
two  main  reasons.   The  first  reasc  i  was  that  the  development  of  EDOM  was 
taking  much  longer  time  than  was  originally  estimated  and  its  completion  by 
the  scheduled  deadline,  September  1,  1970,  was  considered  totally  impossible. 
An  extension  of  the  deadline  was  also  considered  impossible,  because  other 
activities  related  to  EDOM  were  proceeding  according  to  their  schedules. 
Particularly,  lack  of  budget  for  EDOM  was  a  crucial  factor  for  the  dis- 
continuation of  the  project.   The  second  reason  was  strictly  economic. 
Observing  IBM's  massive  efforts  put  into  IMS,  the  group  realized  that  the 
present  manpower  for  EDOM  would  be  totally  inadequate  to  develop  a  system 
comparable  to  the  IMS  and  further  to  make  improvements  similar  to  those 
planned  for  IMS  by  IBM.   Besides,  the  economic  recession  in  1970  forced  the 
information  systems  group  to  reduce  the  size  of  its  programming  staff  and 
redeploy  experienced  programming  personnel  away  from  the  EDOM  project  to 
the  ICED  project.   Soon  after  making  the  decision  to  use  IMS,  the  group 
contacted  a  West  coast  firm  that  had  been  using  IMS  to  obtain  information 
on  the  latter^  experience  with  the  system. 

During  the  period  of  late  1969  to  early  1970,  the  data  processing  center 
of  the  division  was  equipped  with  one  IBM  360/65,  one  IBM  360/50,  and  two 
Honeywell  415's.  The  IBM  360/65  was  installed  in  August  1969  to  take 
over  the  entire  data  processing  work  formerly  done  by  an  IBM  1400.   This 
was  a  batch-to-batch  conversion  without  any  change  in  processing.  The 
IBM  360/50  was  used  to  emulate  the  IBM  1400.   One  of  the  Honeywell  computers 
had  been  used  by  the  central  document  issue  specifications  group  for 
tracking  and  controlling  the  issued  documents  with  9  to  12  CRT  terminals. 
The  other  was  used  to  record  statistical  data  on  test  equipment.   These 
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Honeywell  computers,  each  costing  approximately  $15,000/month,  were  soon 
to  be  phased  out  with  the  completion  of  ICED  planned  to  be  processed  by 
IMS.   All  hardware  was  leased  from  leasing  companies  for  a  minimum  of  six 
years  and  an  average  period  of  7.5  years.   In  the  fall  of  1970,  just  before 
the  installation  of  IMS  in  the  IBM  360/65,  the  computer  had  756  K  bytes  of  core 
storage  of  which  600  K  bytes  were  used  for  batch  processing,  leaving  only 
156  K  bytes  available  for  IMS.   To  enhance  the  capacity,  one  module  of  IBM's 
Large  Core  Storage  (LCS)  with  one  mega  bytes  and  eight  micro  second  in 
access  time  was  added  to  main  storage  on  a  30-day  rental  basis.   Subsequently, 
the  IBM  LCS  was  replaced  by  one  unit  of  AMPEX's  LCS  which  was  considered 
superior  in  performance  (two  micro  second  in  access  time)  and  lower  in 
cost  (about  1/3  of  the  cost  of  an  IBM  LCS). 

Period  of  Initial  Experience,  September  1970-December  1971 

In  its  initial  phase  of  installation  during  the  period  of  September- 
December  1970,  IMS  Version  1,  simply  called  IMS  1,  failed  to  deliver  the 
expected  performance.   The  problem  was  mainly  one  of  maintaining  the 
software.   IBM  supplied  the  information  systems  group  with  a  list  of  instructions 
to  correct  90  known  incidents  caused  by  coding  bugs.   But  the  shortage  in  the 
IMS  programming  staff  created  by  the  redeployment  of  some  members  to  the  ICED 
project  made  it  impossible  to  complete  the  debugging  until  the  beginning  of  1971. 

Around  this  time,  ICED  was  the  only  application  program  handled  by  IMS, 
using  six  Sanders  620  CRT  terminals.   On  the  average,  about  6,000  terminal 
transactions,  were  processed,  mostly  related  to  queries  on  engineering 
drawings,  factory  completion  dates,  components  requirements,  geographical 
location  codes,  and  product  codes.   The  response  time  was  5-7  seconds/call 
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for  about  98%  of  the  terminal  messages.   But  the  remaining  messages  took 
a  very  long  response  time;  they  took  three  hours  to  complete  in  several 
occasions,  and  five  hours  in  the  worst  case.   These  exceptional  cases  appeared 
at  random  and  independent  of  the  load  on  IMS  at  the  moment.   In  these  cases, 
messages  entered  on  line  items  created  what  appeared  to  be  an  endless  chain 
of  repeated  explosions  of  product  items  at  each  of  which  an  item  was  decomposed 
to  sub-items  for  update.   This  was  caused  by  the  way  the  database  was 
defined  for  the  application.   By  August  1971,  the  redesign  of  the  database 
was  completed,  finally  solving  the  problem  of  response  time.   The  ICED 
program  itself  was  not  altered  at  that  time  and  virtually  stayed  unchanged 
since-  then.  At  present,  if  the  response  time  to  a  terminal  message  is  very 
slow,  the  operator  will  call  the  master  operator  at  the  computer  center  and 
request  an  interruption  and  termination  of  the  processing.   Or  if  the  terminal 
operator  detects  some  errors  in  processing,  she  will  request  the  master  operator 
to  reprocess  the  original  message.   There  is  no  way  for  the  master  operator, 
however,  to  determine  if  the  processing  of  a  message  by  IMS  is  taking  too  long. 

In  October  1971,  IMS  Version  2,  or  simply  IMS  2,  replaced  IMS  Version  1 
then  in  use.   About  the  same  time  another  module  of  AMPEX's  LCS  with  one 
mega  bytes  was  added  to  the  IBM  360/65 's  main  storage  mainly  to  increase 
the  batch  processing  region.   Although  the  new  version  was  designed  to  enhance 
IMS's  capability,  it  was  plagued  with  initial  software  bugs.   As  a  result, 
in  the  first  few  months  of  the  installation,  the  systems  group  was  kept 
constantly  busy  with  a  sequence  of  unpredictable  problems  when  none  of  its 
members  was  really  familiar  with  the  internal  working  of  the  new  version.   In 
one  case,  data  were  stored  by  the  malfunctioning  IMS  in  such  a  faulty  manner 
that  the  regular  recovery  method  became  useless.   During  this  period,  there 
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was  a  machine  down  lasting  four  days  Chat  compounded  the  already  bemuddled 
situation.  Because  of  the  complexity  of  IMS  2,  many  months  were  spent  for 
debugging  before  it  was  finally  running  satisfactorily  toward  the  end  of  1971. 

IMS  2  was  superior  to  IMS  1  in  three  main  points.   First,  IMS  2  introduced 
two  new  access  methods,  the  Hierarchical  Indexed  Direct  Access  Method  (HIDAM) 
and  the  Hierarchical  Direct  Access  Method  (HDAM) .   Particularly,  HIDAM  made  it 
possible  to  store  new  data  in  locations  formerly  occupied  by  deleted  data, 
greatly  improving  the  efficiency  in  the  utilization  of  disk  storage.   This 
was  not  possible  by  the  Hierarchial  Indexed  Sequential  Access  Method  (HISAM) , 
the  only  indexed  access  method  available  to  IMS  1.   Second,  the  introduction 
of  a  database  buffer  pool  with  IMS  2  greatly  improved  the  response  time. 
The  function  of  the  database  buffer  pool  needs  a  brief  explanation  at  t 
point.   IMS  uses  a  set  of  core  regions  called  "message  regions",  each  of 
is  created  to  process  specific  types  of  messages.  When  an  incoming  terminal 
message  finds  an  unused  message  region  allocated  to  its  type,  it  will  be 
processed  promptly  by  IMS.   Otherwise,  it  waits  in  a  queue  until  one  of  the 
message  regions  for  the  transaction  type  becomes  available.   Processing  the- 
transaction  is  done  by  calling  necessary  segments  of  the  database  into  the 
message  region.   Under  IMS  1,  the  database  segments  used  are  sent  back  to  the 
database  immediately  after  the  completion  of  the  process.   In  contrast,  under 
IMS  2  the  database  segments  completing  the  process  are  placed  on  the  top  of 
the  database  buffer  pool,, pushing  down  the  existing  database  segments. 
Eventually  the  oldest  segments  are  pushed  out  of  the  buffer  pool   in  the 
manner  of  FIFO  and  are  sent  back  to  the  database  in  disk  storage.   Active 
database  segments  that  are  frequently  used  by  messages  have  high  probabilj 
of  being  kept  in  the  buffer  pool  and  readily  available  for  subsequent  pre: 
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thus  saving  transfer  times  for  retriving  them  from  and  sending  them  back  to 
the  database  in  disk  storage. 

The  third  improvement  in  IMS  2  concerns  the  log  tape.   With  IMS  1,  all 
database  segments  used  by  messages  are  recorded  on  the  log  tape  regardless 
of  whether  there  are  changes  in  the  segments,  whereas  IMS  2  stores  only 
changes  created  in  the  segments.   As  a  result,  IMS  2  needed  only  4  or  5 
tape  reels  to  log  messages  at  this  division  on  a  typical  day  when  IMS  1 
might  have  required  8-9  tape  reels.   The  provision  of  log  tapes  for  possible 
recovery  of  data  is  one  of  the  valuable  assets  of  IMS.   However,  the  recovery 
rarely  became  necessary  at  this  division. 

Period  of  Expanding  Use,  October  1971-March  1973 

In  October  1971,  the  initial  phase  of  the  Inventory  Maintenance  and 
Control  Program  (IMAC)  was  installed  as  the  second  application  to  be  pro- 
cessed by  IMS.   At  this  time,  IMAC  had  only  one  module  related  to  inventory 
control  of  line  items.   Subsequently,  late  November  1971,  the  Customer  Order 
Processing  (CORP)  became  the  third  application  to  use  IMS.   The  second  and 
third  applications  used  a  common  database.   By  the  end  of  1971,  a  maximum 
of  20,000  IMS  transactions  were  entered  daily  from  about  30  Sanders  620 
CRT  terminals. 

Meanwhile,  the  function  of  IMAC  was  expanded  by  additional  modules. 
These  modules  exploded  every  ordered  line  item  not  available  in  inventory 
into  piece  parts  requirements,  and  recorded  the  movement,  of  every  lot  of  goods 
for  quality  control,  marking,  packaging,  or  warehousing.  When  a  lot  was 
rejected  in  quality  control,  IMAC  initiated  the  reordering  of  a  new  lot.   The 
installation  of  IMAC  was  made  possible  by  the  enhanced  capability  available 
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with  IMS  2.   By  early  1972,  IMAC  and  CORP  were  very  busy  receiving  a  great 
number  of  terminal  messages.   Particularly,  messages  for  CORP  created  a 
stress  on  IMS,  causing  the  general  deterioration  in  terminal  response  time. 
Meanwhile,  CORP  went  through  successive  improvements  with  new  additional 
modules . 

Early  1972,  an  IBM  370/165  was  installed  and  run  in  parallel  with  the 
existing  IBM  360/65;  the  former  was  dedicated  to  IMS  and  the  latter  to  batch 
processing.   But  the  IBM  370/165  had  to  go  through  the  initial  shakedown 
common  to  new  hardware,  further  compounding  the  problem  of  deterioration  in 
response  time  rather  than  solving  it.   By  the  end  of  May,  the  hardware 

problem  was  smoothed  out  and  IMS  was  functioning  satisfactorily.   As  a 
result,  the  IBM  360/65  was  finally  taken  out  and  the  IBM  370/165  started 
to  handle  both  IMS  and  batch  processing  jobs.   Meanwhile  the  total  number 
of  terminals  installed  for  IMS  messages  steadily  increased,  from  about  30 
units  of  Sanders  620's  at  the  end  of  1971  to  about  75  units  in  the  middle 
of  1972.   Of  the  75  units,  60  units  were  Sanders  620's  used  for  ICED  and 
CORP,  and  15  units  were  IBM  1050 fs  and  2740's  used  as  auditor  terminals  for 
exception  reporting  in  IMAC.   During  June  1972,  between  20,000  and  30,000 
terminal  messages  were  processed  by  IMS  daily.   Of  this  amount,  7,000-8,000 
belonged  to  ICED,  about  the  same  amount  to  IMAC,  and  the  rest  to  CORP.   The 
response  time  was  2-3  seconds  per  transaction  during  a  period  of  normal 
load,  and  about  8  seconds  on  the  average  and  15-20  seconds  at  the  most 
during  a  period  of  peak  load.   The  system  performance  was  considered 
satisfactory  and  there  was  no  user  complaint. 

In  the. summer  of  1972,  the  CORP  program  was  expanded  to  incorporate 
modules  for  shipping  and  scheduling  for  some  line  items.   Previously,  each 
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entering  order  required  processing  and  displaying  by  the  following  separate 

modules : 

1.  ORDER  HEADER 

2.  ORDER  SKIP  TO/SOLD  TO 

3.  MULTIPLE  LINE  ITEMS 

4.  ORDER  LINE  ITEMS 

5.  ORDER  PRICE 

6.  ORDER  INSTRUCTIONS 

7.  PRINT  DITTOMASTER 

8.  SHIPPING  DATA/LINE  ITEMS  SHIPMENTS 

In  the  expanded  CORP  program,  the  number  of  modules  to  be  processed  and 
displayed  was  increased  to  3  or  4  times  the  above  number.   The  previous 
program  processed  only  orders  on  line  items,  whereas  the  new  one  processed 
orders  on  line  items  and  exploded  each  line  item  into  sub- items,  of  which 
inventories  and  shipment  schedules  were  to  be  handled  by  IMAC.   Thus,  a  single 
order  entering  through  CORP  initiated  many  background  transactions  processed 
by  IMAC,  which  created  two  problems:   one  was  a  prolonged  processing  time 
required  for  each  entering  order;  and  the  other  was  that  the  long  chain 
of  processes  initiated  by  CORP  produced  frequent  intent  conflicts  with 
terminal  messages  directly  entering  into  IMAC  because  of  a  common  database 
used  by  CORP  and  IMAC.   The  intent  conflict  is  a  contention  between  messages 
to  update  segments  belonging  to  the  same  segment  type  in  the  database.   IMS2 
like  IMS  1  allowed  only  the  first  message  to  use  a  particular  segment  type  for 
update  and  let  the  remaining  messages  wait  in  the  queue  for  their  turns.   But 
until  the  expansion  of  CORP  in  the  summer  of  1972,  the  intent  conflict  had 
never  been  a  serious  problem. 
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In  October  1972,  IMS  2.2  replaced  IMS  2  then  in  use.   IBM  never 
marketed  IMS  2.1.   The  introduction  of  the  new  version  was  accompanied 
by  initial  bugs  usually  associated  with  a  new  software  package.   Efforts 
to  eliminate  these  bugs  continued  till  March  1973.   The  expanded  format  of 
CORP  introduced  during  the  summer  of  1972  covered  only  a  limited  number  of 
line  items.  With  the  introduction  of  IMS  2.2,  the  coverage  of  the  format 
was  expanded  to  the  entire  line  items.   In  the  ensuing  period,  November 
1972  -  March  1973,  the  expanded  coverage  resulted  in  a  great  increase  in  the 
number  of  terminal  messages  related  to  CORP  and  IMAC,  causing  a  serious 
deterioration  in  response  time.   During  this  period,  the  number  of  terminal 
messages  reached  60,000  per  day  with  an  average  response  time  of  45  seconds  - 
1.5  minutes  and  a  peak  load  response  time  of  2-3  minutes  around  11  a.m.  and 
2:00  -  3:30  p.m. 

Period  of  Improved  Use,  March  1973  -  July  1973 

Around  March  1973,  a  team  composed  of  2  systems  programmers  and  4 
application  programmers  was  organized  to  carry  out  a  project  to  improve  the 
performance  of  IMS  which  had  by  then  developed  serious  deterioration  in 
response  time.   This  project  lasting  through  the  following  May  introduced 
changes  in  hardware  and  software.   One  hardware  change  was  an  addition  of 
one  mega  bytes  to  main  storage  of  which  200  K  bytes  were  allocated  to  IMS. 
The  increased  storage  available  to  IMS  brought  about  two  improvements: 
(1)  an  increase  in  the  size  of  the  database  buffer  pool  from  30  K  bytes  to 
50  K  bytes,  and  (2)  an  increase  in  the  number  of  message  regions  from  three 
to  four.   Although  both  improvements  helped  reduce  the  response  time  greatly, 
the  first  one  was  the  primary  factor  for  that  reduction.   Terminal  messages 
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were  now  possible  to  find  necessary  segments  of  the  database  readily 
available  in  the  expanded  database  buffer  pool  75%  to  80%  of  the  time  in 
contrast  to  60%  to  70%  of  the  time  with  the  previous  buffer  pool. 

The  change  in  software,  more  specifically  applications  programs,  was 
mainly  to  reduce  the  probability  of  creating  an  intent  conflict.   This  was 
done  by  reviewing  a  specific  code  used  in  the  existing  programs.   There  are 
two  types  of  update  codes  available  to  IMS,  both  of  which  are  equally  potent 
in  creating  an  intent  conflict;  one  code  is  straight  UPDATE  and  the  other 
mixed  INQUIRY/ UPDATE.  Until  the  time  of  the  improvement  project,  application 
programmers  were  generally  not  fully  aware  of  the  serious  deterioration  of 
response  time  that  could  be  created  by  the  intent  conflict,  and  used  Inquiry/ 
Update  without  care  even  when  the  update  process  did  not  always  follow  the 
inquiry  process.   The  improvement;  project  team  re-examined  every  existing 
message  with  INQUIRY/UPDATE  and,  whenever  possible,  broke  up  the  message 
into  a  message  with  INQUIRY  and  another  with  UPDATE.   This  modification  in 
codes  was  to  improve  the  response  time  in  two  ways:  one  was  that  the  inquiry 
process  could  be  performed  without  the  interference  of  an  intent  conflict; 
and  the  other  was  that  the  lock-up  duration  of  the  segment  type  would  be 
reduced  by  using  straight  UPDATE  in  place  of  mixed  INQUIRY /UPDATE  if 
updating  had  to  follow  inquiring. 

The  above  changes  in  hardware  and  application  programs  produced  a 
major  improvement  in  response  time.   Before  these  changes,  around  March  of 
1973,  about  40%  -  50%  of  terminal  messages  had  to  wait  in  the  queue  because  of 
intent  conflicts;  at  one  time,  there  were  no  less  than  30  messages  waiting  in 
the  queue.   The  response  time  of  a  terminal  message  then  was  about  2  minutes 
at  a  peak  load  time,  whereas  after  the  above  changes,  it  was  3-5  seconds 
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on  Che  average  and  8-10  seconds  at  a  peak  load  time  with  at  the  most  a 
few  transactions  waiting  in  the  queue  at   any  moment. 

As  a  part  of  the  project,  the  team  invited  an  IMS  specialist  from 
outside  to  diagnose  the  CORP  and  IMAC  programs  whose  messages  constituted  the 
major  portion  of  the  current  IMS  workload,   After  two  days  of  the  study,   he 
submitted  the  following  observations  and  suggestions: 

(1)  Two  modules  A41  and  A98  of  the  order  entry  application  processed 
about  5000  messages  each  day.   A25  entered  orders  on  individual 
line  items  separately  into  the  document  database  and  then 
automatically  generated  the  processes  of  A98.  A98  in  turn 
processes  a  number  of  things,  such  as  checking  demand  details 
against  inventory  or  releasing  piece  parts  from  the  shop.  A41 

and  A98  create  three  levels  of  processing  for  each  exploding  trans- 
action and  read  the  same  series  of  segments  at  all  three  levels. 
The  suggestion  is  the  consolication  of  A41  and  A98  by  combining 
the  three  levels  into  one  for  a  major  portion  of  the  work. 

(2)  Module  A61  of  Che  order  entry  application  processes  the  shipping 
transaction.   For  each  line  item  ordered,  it  initiates  a  large 
number  of  background  messages  to  be  processed  by  module  A62. 
This  module  releases  piece  parts  from  inventory  for  the  ordered 
item  and  prints  out  a  usage  detail  for  each  of  the  released  piece 
parts.   For  example,  a  single  A61  transaction  may  generate  up  to 
99  background  messages.   This  explosion  may  be  repeated  at  two 
more  levels.   Each  third  level  message  may  require  to  search 
exceedingly  long  overflow  chains,  some  of  which  are  as  long  as 
6000  segments.   The  suggestion  is  to  divide  A62  messages  into 
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groups,  each  composed  of  some  10  messages,  and  to  process  these 
groups  separately. 

(3)  No  strong  database  administration  function  exists  at  this  division. 
Instead,  this  function  has  been  left  to  the  application  group. 
Currently,  a  new  independent  database  is  created  for  every  new 
application.   The  result  is  a  proliferation  of  databases.   This  is 
a  type  of  problem  that  should  be  controlled  by  database  administra- 
tion.  It  is  suggested  to  create  a  database  administrator  who  must 
be  independent  of  the  programming  groups  and  have  the  power  to 
assure  the  company  interests  ahead  of  individual  applications. 

(4)  System  design  review  is  another  area  requiring  an  immediate 
attention.   It  appears  that  new  applications  are  not  subject  to 
any  kind  of  technical  review.   Since  each  new  group  tends  to  use 
new  personnel,  the  same  mistakes  are  repeated  many  times.   Benefits 
from  previous  experiences  are  not  filtering  down  to  systems 
designers  and  programmers. 

Clearly,  the  main  burden  of  the  first  two  recommended  changes  would  fall 
on  the  application  group  while  the  last  two  were  problems  to  be  solved  by  the 
manager  of  the  information  systems  group.   But  to  the  time  of  this  reporting, 
none  of  the  recommendations  had  been  realized.   The  reason  seemed  to  be  that 
the  project  was  the  creation  by  the  managers  of  the  systems  and  application 
groups  without  participation  of  higher  management  that  could  enforce  these 
managers  to  adopt  the  recommended  changes. 

Late  May  1973,  the  account  receivable  database  that  had  hitherto  been 
used  in  batch  environment  was  placed  under  the  control  of  IMS  as  an  extension 
module  of  the  Order  Processing  Application  (CORP) .   During  the  subsequent 
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summer,  4,000  -  5,000  terminal  messages  used  this  database  with  an  average 
response  time  of  5  -  8  seconds.   About  5%  of  these  messages  were  entered 
during  peak  periods  and  processed  with  an  average  response  time  of  about  30 
seconds . 

In  the  summer  of  1973,  the  IBM  370/165  at  the  computer  center  had  3 
mega  bytes  of  main  storage  which  were  allocated  to  various  uses  as  follows: 

IMS  776K  bytes 

TSO  476K  bytes 

HASP  129K  bytes 

0S/MVT  250K  bytes 

TCAM  (terminal  use  for  TSO)  80K  bytes 

batch  processing  the  remainder 

Of  the  776K  bytes  allocated  to  IMS,  264K  bytes  were  allocated  to  four 
message  regions,  and  512K  bytes  to  the  control  region  with  the  following 
specific  purposes: 

database  buffer  pool      50  K  bytes 

terminal  I/O  30  K  bytes 

general  purpose  pool      30  K  bytes 

PSB  pool  40  K  bytes 

IMS  software  the  rest 

The  main  part  of  the  peripheral  equipment  consists  of  three  IBM  3330 
disk  drives  having  a  total  of  24  spindles,  each  with  100  mega  bytes.   Of 
the  24  spindles,  seven  spindles  with  a  total  of  700  mega  bytes  were  used  to 
store  databases  for  IMS.   At  the  end  of  June  1973,  the  channel  associated 
with  these  units  was  busy  70  -  807o  of  the  time,  indicating  a  high  probability 
of  channel  contention.   Other  peripheral  equipment  included  24  IBM  3420-5 
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magnetic  tape  drives,  an  IBM  2305  fixed  head  storage,  135  terminals  of  various 
types,  four  printers,  two  card  readers,  and  many  keypunches.   Two  of  the  24 
IBM  3420-5  tape  drives  were  used  to  maintain  log  tapes  for  IMS.   One  of  them 
was  in  operation  at  a  time  and  automatically  switched  to  the  other  as  soon 
as  its  tape  comes  to  an  end.   During  this  switching,  IMS  suspends  its  operation. 
The  IBM  2305  magnetic  drum  was  used  to  provide  storage  regions  for  Application 
Control  Blocks  (ACB) ,  the  operating  system,  and  TSO  message  swapping.   Every 
application  program  needs  an  ACB  that  defines  databases,  data  structures, 
and  methods  of  using  these  databases.   At  this  time,  109  terminals  were  installed 
to  use  IMS;  of  these,  48  units  were  used  for  IMAC,  15  units  for  ICED,  8  units 
for  CORP,  5  units  for  the  account  receivable  application,  1  unit  for  the 
account  payable  application,  26  units  for  special  projects,  and  6  units  for 
use  by  the  computer  center  staff. 

Meanwhile,  the  total  volume  of  messages  handled  by  IMS  steadily  increased 
from  about  60,000/day  in  March  1973  to  100,000  -  110,000  in  the  following  June 
of  which  8%  required  updates.   IMS  was  performing  satisfactorily  with  only 
occasional  complaints  coming  from  user  departments  when  the  response  time 
became  exceptionally  poor. 

Around  the  middle  of  July  1973,  IMS  2.3  replaced  IMS  2.2.   The  new 
version  was  said  to  incorporate  some  features  to  decrease  the  CPU  time 
required  for  overhead  work  and  to  reduce  the  probability  of  an  intent  conflict. 
But  no  one  knew  exactly  the  natures  of  these  features.   About  the  time  of  the 
conversion  to  IMS  2.3,  the  principal  IMS  systems  programmer  made  several 
changes  in  the  definitions  of  databases.   The  combination  of  the  conversion 
to  IMS  2.3  and  the  changes  in  the  databases  produced  a  significant  improvement 
in  the  IMS  performance.   Taking  the  same  time  frame  of  a  peak  period,  10  -  11  a.m., 


21 

the  thruput  on  a  typical  day  had  increased  from  about  8,000  terminal 
messages  under  IMS  2,2  to  about  9,**0r-  messages  under  IMS  2,3,  thus 
showing  an  improvement  of  about  17%, 

Period  of  Uncertainty^:  ,a^^r,  „J,}f^  i9,?,r 

The  observation  of  the  use  of  IMS  at  this  division  was  made  through 
July  1973.  At  that  time,  the  IMS  application  group  was  planning  to 
install  additional  application  programs  in  coming  months.   IMAC  would 
have  a  module  for  incoming  quality  assurance  in  August  and  then  a 
module  for  production  scheduling.   In  the  subsequent  fall,  the  applica- 
tion group  was  planning  to  add  the  purchasing  and  receiving  modules  to 
IMAC  and  a  module  enabling  field  sales  offices  to  make  inquiries  on 
order  status*  These  additions  were  to  be  completed  around  October  1973 
when  the  total  number  of  terminal  messages  handled  by  IMS  might  reach 
180,000  -  200,000  daily, 

To  cope  with  a  rapid  increase  in  the  volume  of  terminal  messages 
expected  in  the  near  future,  the  IMS  systems  group  laid  out  a  few 
concrete  plans  on  hardware.   One  plan  was  to  reduce  the  probability  of 
a  disk  channel  contention  by  spreading  active  segments  of  databases, 
currently  concentrated  into  a  few  disk  units ,  evenly  ever  a  large 
number  of  disk  units,  The  existing  IBM  370/165  handled  all  types  of 
jobs,  but  it  gave  top  priority  tc  IMS  and  let  TS0  and  RJE  compete  with 
batch  processing  for  the  remaining  CPU  time.   As  a  result,  the  perfor- 
mances of  TSO  and  RJE  were  considered  very  sluggish.  To  alleviate  this 
condition,  an  IBM  370/158  with  3  mega  bytes  of  large  core  storage  was 
scheduled  to  be  installed  in  August  to  take  over  jobs  related  to  TSO 
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and  RJE  from  the  IBM  370/165.  After  this,  batch  processing  would  be 
handled  by  the  two  CPU's,  The  addition  of  the  IBM  370/158  would  defi- 
nitely improve  work  related  to  TSO  and  RJE  and  decrease  their  conflicts 
with  batch  processing.  But  it  would  not  improve  the  performance  of  IMS 
greatly,  since  IMS  was  already  given  top  priority  by  the   existing  IBM 
370/165.   In  October,  this  computer  was  to  be  replaced  by  an  IBM  370/168, 
which  would  result  in  an  increase  of  about  20%  in  CPU  speed. 

From  the  past  experience,  the  systems  group  knew  that  they  could 
handle  a  gradual  increase  in  the  volume  of  IMS  messages,  but  considered 
that  the  existing  system  in  July  1973  was  already  very  close  to  the 
degradation  point  and  might  not  be  able  to  absorb  another  major  appli- 
cation program.  On  the  other  hand,  if  the  application  group  was  going 
to  make  modifications  in  the  existing  programs  according  to  the 
recommendations  made  by  the  consultant  in  the  preceding  spring,  in  the 
opinion  of  the  systems  group,  the  system  with  the  scheduled  hardware 
improvements  could  handle  as  many  as  150,000  -  200,000  terminal  messages 
daily  as  compared  with  the  current  volume  of  100,000  -  110,000  messages 
in  July  1973.  With  the  above  improvements  in  hardware  and  software, 
the  systems  might  be  able  to  handle  both  the  existing  applications  and 
additional  ones  to  be  installed  in  the  following  few. months.  Eventually, 
towards  the  end  of  1973,  the  inadequacy  of  IMS  2.3  would  make  the  system 
incapable  of  handling  all  incoming  messages  if  new  application  programs 
were  to  be  added  as  ascheduled.   The  main  factor  of  the  inadequacy  was 
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attributable  to  the  way  in  which  IMS  2.3,  like  tte  previous  versions,  create 
intent  conflicts. 

The  systesss  group  considered  that  the  only  solution  to  the  doomed  IMS 
operation  was  the  replacement  of  IMS  2,3  with  IMS  VS  which  was  scheduled 
to  be  introduced  in  the  beginning  of  1974.   As  in  the  previous  case,  the  new 
version  was  expected  to  require  a  few  months  of  testing  and  debugging  before 
it  would  become  operational.   IMS  VS  was  believed  to  solve  many  of  the  problems 
causing  deterioration  in  response  time  under  the  present  IMS  2,3.   In 
particular,  under  IMS  VS,  an  intent  conflict  would  exist  if  more  than  one 
message  were  to  update  the  same  segment  rather  than  the  same  segment  type 
as  under  IMS  2.3.   Therefore  IMS  VS  was  believed  to  eliminate  a  major  part 
of  the  existing  intent  conflicts.   One  opinion  was  that  it  might  be  an 
improvement  of  almost  100%,  so  that  the  total  number  of  messages  could  reach 
200,000/day  without  system  degradation.   Another  opinion  was,  however,  that 
the  improvement  depended  much  on  the  types  of  new  messages  to  be  processed 
by  IMS.   Without  knowing  the  details  of  application  programs  currently  being 
developed  and  the  times  of  their  installations,  the  systems  group  waited 
the  coming  fall  with  anxiety  and  without  concrete  plans. 

Concluding  Remarks 

There  is  no  database  management  system  as  flexible  as  IMS,   The 
information  systems  group  considered  IMS  quite  satisfactory  despite  the 
fact  that  it  had  experienced  difficulties  with  the  system  at  times  in  the 
past.   The  group  thought  that  IMS's  backup  and  recovery  features  were 
excellent;  DL/I  codes  and  access  methods  were  very  satisfactory;  but  the 
system  occupied  a  too  big  region  in  main  storage  and  was  considered 
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expensive  to  maintain.   One  of  the  serious  problems  with  IMS  was  lack  of  a 
useful  tool  to  measure  and  predict  the  performance  of  the  system,   No 
currently  available  tool  explained  why  response  time  suddenly  increased, 
for  example,  from  8  seconds  to  40  seconds.   A  simulation  tool  replicating 
the  user  environment  would  be  very  useful,  but  developing  such  a  simulation 
program  might  require  a  major  effort  beyond  the  available  resources  of  the 
information  systems  group.   IBM  had  a  simulation  package  called  IMS-AIDE 
designed  to  diagnose  the  performance  of  IMS  under  a  given  set  of  conditions 
assumed  to  represent  the  user  environment.   This  package  was  used  to 
investigate  the  response  time  at  this  division  under  variable  conditions. 
But  the  result  of  the  investigation  consistently  underestimated  the  actual 
response  time  with  a  wide  margin,  showing  a  serious  defect  of  a  tool  design- 
ed to  measure  the  performance  of  the  database  management  system.   The  version 
for  the  defect  seemed  either  that  IMS-AIDE  treated  the  IMS  problem  as  a 
straight  queueing  problem  without  intent  conflict,  assuming  all  messages 
to  be  independent;  or,  otherwise,  it  did  not  fully  cover  possible  types 
of  intent  conflicts. 

The  user  of  a  database  management  system  in  on-line  processing 
environment  is  generally  concerned  with  the  response  time  of  a  terminal 
message.   In  the  present  case,  serious  deterioration  in  response  time 
occurred  in  a  few  occasions.   In  each  occasion,  the  wisdom  of  using  IMS  was 
hotly  debated  within  the  information  systems  group.   One  main  reason  for 
the  deterioration  was  the  unfamiliarity  of  application  programmers,  who 
had  been  trained  for  batch  processing,  with  the  nature  of  online  real-time 
processing  using  common  databases.   They  tried  to  perform  the  entire  process 
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of  a  terminal  message  in  one  continuous  run  regardless  of  the  amount  of 
time  required  as  they  had  done  with  a  job  in  batch  processing.   What  seemed 
to  be  needed  in  this  case  was  some  guidelines  whereby  a  programmer  could 
divide  the  process  required  of  a  terminal  message  into  two  segments,  a 
real-time  processing  segment  and  a  batch  processing  segment  that  could 
be  performed  later. 

Database  administration  was  another  new  problem  that  faced  the 
information  systems  group.   Formerly,  each  program  in  batch  environment 
was  usually  developed  independent  of  other  programs.   In  using  IMS,  the 
group  realized  the  need  of  an  administrator  whose  duties  were  to  ensure 
the  effective  design  and  efficient  use  of  non-redundant  databases,  and 
to  coordinate  the  activities  of  teams  engaged  in  the  development  of 
different  application  programs  using  common  databases. 
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